An application running on a “smart” payment card or other payment device, together with a personal card reader, can be used to create a unique code (for example, one that only the issuer can decode) that can be sent to an issuer. This can ensure to the issuer that the card that created the code is genuine. Additionally, by having the card or other payment device carry out personal identification number (PIN) verification, so that, for example, a card will only create the aforementioned code when a PIN has been verified, the issuer can then determine that the card is genuine and that the person using the card is arguably the correct cardholder (since he or she has entered the correct PIN). Accordingly, the issuer, based on this established level of trust, will allow certain actions to take place.
It is known to reset data elements or risk management parameters on a chip based banking card by receiving an authentication code from the card issuer, during an online process wherein the card is captured in a merchant's terminal. For example, the terminal and network infrastructure based on EMVCo allows updates as part of an online authorization response and implements three mechanisms for doing so:                Updates prior to the 2nd Generate AC—the so-called critical scripts (tag 71, described in EMV specifications)        Issuer Authentication data, sent as part of the 2nd Generate AC (tag 91, described in EMV specifications) or in an External Authenticate command (described in EMV Specifications)        Updates after the 2nd Generate AC—the so-called non-critical scripts (tag 72, described in EMV specifications).        